Secure implementation and utilization of device-specific security data

ABSTRACT

A tamper-resistant electronic circuit is configured for implementation in a device. The electronic circuit securely implements and utilizes device-specific security data during operation in the device, and is basically provided with a tamper-resistantly stored secret not accessible over an external circuit interface. The electronic circuit is also provided with functionality for performing cryptographic processing at least partly in response to the stored secret to generate an instance of device-specific security data that is internally confined within said electronic circuit during usage of the device. The electronic circuit is further configured for performing one or more security-related operations or algorithms in response to the internally confined device-specific security data. In this way, secure implementation and utilization device-specific security data for security purposes can be effectively accomplished. The security is uncompromised since the stored secret is never available outside the electronic circuit, and the device-specific security data is internally confined within the circuit during usage or operation of the device.

This application is the US national phase of international applicationPCT/SE2003/001660 filed 27 Oct. 2003 which designated the U.S. andclaims benefit of U.S. Provisional Application 60/422,498, filed 31 Oct.2002, the entire contents of each of which are hereby incorporated byreference.

TECHNICAL FIELD

The technical field generally relates to management, implementation andutilization of device-specific security data for various purposes, andmore particularly to secure and efficient procedures for providingdevices with such device-specific security data.

BACKGROUND

There is a general need for implementing and utilizing device-specificsecurity data in a wide variety of different devices such as mobiletelephones, personal computers, cameras, audio devices, servers, basestations and firewalls. Device-specific security data can be used forvarious purposes, including management of security issues in relation tocommunication over insecure networks, content-marking of digital contentand so forth.

To facilitate the understanding of a rationale behind the presentinvention, it may be helpful to think of the manufacturing process ofdevices in large volumes. In particular, it may for example be useful toconsider a device manufacturer, with limited trust in any third party(in particular third party chip manufacturers), that needs to producedevices containing tamper-resistantly protected and per-device uniquecryptographic keys and/or other security data to a low cost.

In network communication, for example, data security is often based onsome sort of security data, e.g. a cryptographic key, which is used toestablish data confidentiality, data integrity, authentication,authorization, non-repudiation and/or other security services. With therapid development of Internet, packet data telecommunications networksand other communications networks, it has become increasingly moreimportant to be able to provide proper data security such as protectingmessages exchanged between nodes and/or devices in the network. Forsimplicity, any entity that participates in such communication will bereferred to as a network device, and examples include mobile telephones,personal computers, security gateways, firewalls, radio base stationsand so forth.

There are several difficulties in securely and cost efficientlymanufacturing devices with security data that can later be used e.g. forsecurity issues in connection with network communication:

-   -   To install or implement device-specific security data, different        for each device. This may require entirely new manufacturing        processes for some device components and thus become costly        and/or inefficient.    -   To place the security data in a location within the device such        that it cannot be compromised or manipulated by unauthorized        parties.    -   To ensure that the security data is protected from unauthorized        parties during the entire manufacturing process of the device.        In particular if untrusted parties are involved during        manufacturing, additional security management may be necessary.    -   To securely manage information, related to the security data,        that is needed for an authorized party to later be able to        provide data security in relation to device e.g. setting up a        secure connection with the device. For example, if the device        security data is a shared secret key in a cryptographic        protocol, such as an authentication and/or encryption protocol,        the same key must be available, and only available, for the        authorized communications partner(s) that should be able to set        up the secure connection with the device.

For example, many communication systems of today, including mobilecommunication systems, paging systems, as well as wireless and wirelinedata networks, employ authentication and encryption procedures for thepurpose of improving system security and robustness. The problem ofestablishing secure and robust communication is encountered in manytechnical applications, ranging from general network communication tomore specific applications such as Digital Rights Management (DRM).

In general, there are two solutions for storing security data in adevice, either on a chip or Integrated Circuit (IC) or in some sort ofprogrammable memory, e.g. a PROM, keeping in mind that data stored on anIC is generally more protected.

In reference [1], a master key is stored in the EEPROM of a smart card,and used for encrypting sensitive information to be stored in arelatively less secure storage medium.

Reference [2] discloses a processor, which is connected to an externaldevice for the purpose of downloading a program from the external deviceinto its RAM memory. If the program is encrypted, a decryption modulearranged in the processor accesses a key permanently stored in theprocessor in order to decrypt the program information.

Reference [3] mentions so-called on-board key generation in connectionwith smart cards.

Storing secret data, e.g. a device-specific random number, on an IC ispossible today with standard IC production tools. However, the logisticsfor securely passing the random number or some related data from the ICmanufacturer to the device manufacturer where the IC is used is with thepresent techniques either infeasible/expensive and/or requires specialsecurity management for handling the security data. In general, thedevice manufacturer and the IC manufacturer may be different parties. Ifsome security data is managed by the IC manufacturer then this may be asecurity weakness, a possible target for attacks and may also increasethe costs of the IC.

The same argument applies to the IC manufacturer generating and/orstoring cryptographic keys on an IC on behalf of a device manufacturer.

The device manufacturer can let the IC manufacturer store, on the IC,data that is not possible to extract after IC manufacturing, unless veryadvanced reverse engineering is involved. However, using this devicedata in a security context with the help of state-of-the-art techniquesrequires security management in and between IC manufacturer and devicemanufacturer, and is either not secure or unfeasible/expensive in anindustrialization process, in particular for a mass market.

The device manufacturer can insert security data into PROM thus avoidingto include the IC manufacturer as a trusted third party, and alsoavoiding costly changes in the IC manufacturing process. However,secrets in PROM are not as well protected against an adversary withaccess (even if it is just temporary) to the device. Moreover, the ASIC(Application Specific Integrated Circuit) technology required forrealizing PROM functionality induces considerable extra costs on the IC,for example, through additional masks in the production process of theIC.

In addition, the IC manufacturer may want to limit the use of its ICs tothose device manufacturers that he/she trusts or has business agreementswith.

A somewhat different, but still related problem is for a third party,with trust relations to the device manufacturer and/or the user, tosecurely communicate with the device or with a user of the device. Thesecurity management of the device-specific security data may thusrequire including other parties as well.

SUMMARY

The present invention overcomes these and other drawbacks of the priorart arrangements.

It is an object to implement and utilize device-specific security datain devices such as mobile telephones, personal computers, cameras, audiodevices, servers, base stations and firewalls.

It is an object to provide a method for securely and cost efficientlymanufacturing a device with security data capabilities, as well as amethod for management of security data. In particular, it is desirableto provide the device with tamper-resistantly protected anddevice-specific security data. It is also important to ensure thatsecurity data is protected from unauthorized parties during the entiremanufacturing process of the device, without the need for extensivesecurity management.

Another object is to provide an improved method for maintaining datasecurity in relation to network communication between a network deviceand an external communication partner.

Still another object is to provide an improved method for markingdigital content produced by a content-producing device.

A tamper-resistant electronic circuit is configured for implementationin a device and that securely implements and utilizes device-specificsecurity data during operation in the device. The tamper-resistantelectronic circuit is basically provided with a tamper-resistantlystored secret not accessible over an external circuit interface. Theelectronic circuit is also provided with functionality for performingcryptographic processing at least partly in response to or based on thestored secret to generate an instance of device-specific security datathat is internally confined within said electronic circuit during usageof the device. The electronic circuit is further configured forperforming one or more security- related operations or algorithms inresponse to the internally confined device-specific security data.

In this way, secure implementation and utilization of device-specificsecurity data for security purposes can be effectively accomplished. Thesecurity is uncompromised since the stored secret is never availableoutside the electronic circuit, and the device-specific security data isinternally confined within the circuit during usage or operation of thedevice. This means that the device-specific security data is keptunavailable from the external circuit programming interface and can onlybe used within the circuit to perform a security-related operationduring usage and operation of the device. As a particular example,device-specific security data may be used in conjunction with asecurity-related operation to convert encrypted input information intoclear text output information without revealing the stored secret or thedevice-specific security data itself. The security-related operation maybe a simple operation, such as decryption of encrypted information, or amore complex, composite operation.

The electronic circuit may be an integrated circuit (IC), a smart cardor any other tamper-resistant electronic circuit, though preferably anencapsulated circuit.

The tamper-resistant electronic circuit is generally applicable in awide variety of devices, producing internally confined device-specificsecurity data that can be used for various security-related purposes.

The electronic circuit may for example be arranged in a network device,and the device-specific security data handled by the circuit inoperation within the network device can then be used for data securityoperations in network communication including data confidentiality, dataintegrity, authentication, authorization and non-repudiation. A specificexample involves securing communication over insecure networks,including Internet and cellular communication networks.

In another application scenario, the electronic circuit is arranged in adevice that produces digital content, and the device-specific securitydata handled by the circuit in operation within the content-producingdevice can then be used, e.g. for marking the produced digital contentby generating a device-specific fingerprint embedded into the digitalcontent.

More specifically, at circuit manufacturing, a random secret ispreferably stored securely within the electronic circuit such as an IC.This could be implemented in such a way that not even the circuitmanufacturer knows the secret. This secret data may be any arbitrary orrandomly generated number typically belonging to a large set of numbersto avoid guessing or precomputation attacks. Furthermore, the electroniccircuit is preferably provided with security or cryptographicalgorithm(s) implemented for execution in the electronic circuit withthe secret as (at least partial) input. Once the electronic circuit isinstalled by the device manufacturer for operation in the device, thestored secret may be used together with the cryptographic securityalgorithm(s) for generating an instance of security data that isspecific for the particular device in which the electronic circuit isimplemented.

Thus, the stored secret and the cryptographic algorithm(s) implementedin the electronic circuit allow generation of securely confineddevice-specific security data, e.g. encryption and decryption keys, bindkeys, symmetric keys, private and associated public keys and/or otherdevice-specific security data that can be used for various securityoperations.

In particular, it is clearly advantageous to be able to generatedevice-specific security data and provide fill security functionalitybased on whatever secret, random data that is originally stored in theelectronic circuit by the circuit (IC) manufacturer.

Furthermore, the electronic circuit allows generation and management ofdevice-specific security data for a wide range of devices in which thecircuit may be arranged. In addition, since the secret data is securelystored in the circuit, there is no need for any extensive securitymanagement in the manufacturing of the device or in the distribution ofcircuits between the circuit (IC) manufacturer and the devicemanufacturer.

The cryptographic processing implemented on the electronic circuit ispreferably based on a cryptographic function or algorithm designed sothat it is computationally infeasible to deduce the result of thealgorithm without knowing the secret, and/or to deduce the secret fromthe result.

The secret may be the sole input to the circuit-implementedcryptographic algorithm(s). Alternatively additional input data may besupplied and used together with the secret in the algorithm(s) togenerate the device-specific security data. Preferably, trigger datarequired for generating device-specific security data is defined duringconfiguration of the device, for example in a configuration phase duringmanufacturing or during user configuration. During usage of the device,the predetermined trigger data has to be applied over an externalcircuit interface in order to be able to generate proper security data.Unless the correct trigger data is applied, the cryptographic processingin the electronic circuit normally only generates nonsense data, or doesnot work at all. This implies that some form of predetermined triggerdata is typically required by the electronic circuit in order tointernally re-generate the device-specific security data.

If the trigger data is defined during manufacturing of the device or inconnection thereto, the trigger data may have to be securely transferredfrom the device manufacturer to the device via an intermediate trustedparty such as a network operator to which the user of the device isassociated. Alternatively, the trigger data is defined by anotherconfiguring party such as the network operator and securely transferredto the device. It is also possible to store the predetermined triggerdata in the device already during configuration for easy access when thedevice-specific security data needs to be invoked for a security-relatedoperation. This means that an adversary with physical access to thedevice may possibly gain access to the trigger data or code to performthe security-related operation. However, the adversary will never gainaccess to the device-specific security data itself. In addition, ahigher degree of security may be obtained by protecting the storedtrigger code with a user-selected password.

For example, the trigger data or code may be defined based onconfigurational device-specific security data provided duringconfiguration of the device. Preferably, the electronic circuit isconfigured for generating the trigger data as a cryptographicrepresentation of the configurational device-specific security data,based on the stored secret, wherein the cryptographic representation isoutput over an external circuit interface during the configurationphase. During usage of the device, the device-specific security data isinternally re-generated provided that said additional input correspondsto the cryptographic representation. The configurational security datamay be provided over an external circuit interface during configuration,allowing the device manufacturer or other trusted party to freely selectdevice-specific security data for manufactured devices. However, it isalso possible to internally generate the configurational security datain the electronic circuit during the configuration phase.

In another embodiment, which relates to asymmetric cryptography,suitable additional input such as a prime, a generator of a mathematicalgroup, a nonce and/or a PIN code may be applied to the circuit duringconfiguration of the device, for example during a configuration phase inmanufacturing or during user configuration, for generating an asymmetrickey pair and for outputting the public key over an external circuitinterface. During usage of the device, the corresponding private key isinternally generated or re-generated provided that at least part of thesame additional input is applied over an external circuit interface.

Alternatively, trigger data may be a simple seed, such as a nonce, aso-called bind identity or similar, that is initially applied to theelectronic circuit during configuration of the device, forcing theelectronic circuit to output device-specific security data over anexternal circuit interface in response to a so-called device accesscode. The device access code can be used for making device-specificsecurity data available outside the circuit under certain circumstances,typically in a controlled environment during manufacturing of thedevice, whereas the security data is always internally confined withinthe electronic circuit during usage of the device.

In general, the electronic circuit may be provided with anauthentication protocol for requiring authentication in order to grantaccess to certain functionality in the circuit, thereby effectivelyrestricting usage of the circuit to authorized parties. Typically, theelectronic circuit is configured for authenticating the devicemanufacturer or other configuring party, and for providing a deviceaccess code to the device manufacturer in response to successfulauthentication. For example, the device access code may be generated asa challenge-response pair based on a challenge from the devicemanufacturer and the secret stored on the electronic circuit. Theelectronic circuit may also be configured for disabling internal accessto the stored secret and/or the device-specific security data, unless apredetermined device access code is entered into the electronic circuit.In this way, it can be ensured that only an authorized party, such asthe device manufacturer and/or a trusted party, is allowed to use thestored secret for generation of device-specific security data and/or usethe security data itself.

It should be understood that multiple individual trigger data signalsmight be defined during configuration of the device, where each triggerdata signal is associated with a respective individual device-specificsecurity data. The electronic circuit is then configured for generatinga particular device-specific security data provided that the associatedtrigger data signal is applied to the circuit. This feature may beutilized for providing a multi-user identity module, such as amulti-user SIM (Subscriber Identity Module) for authentication and keyagreement purposes, or a multi-channel decoder, such as a satellite orcable TV decoder, where multiple unique security keys are required.

The technology also relates to additional security management associatedwith the device-specific security data, e.g. certification and trustdelegation, in order to enable trusted third parties to communicatesecurely with the network device and/or user.

The technology offers the following advantages:

-   -   Secure and cost-efficient implementation and utilization of        device-specific security data for security purposes;    -   Uncompromised security, since the stored secret is never        available outside the circuit, and the device-specific security        data is internally confined within the circuit during usage of        the device;    -   Efficient protection of device-specific security data within a        tamper-resistant electronic circuit;    -   Ability to generate device-specific security data and provide        full security functionality based on whatever secret random data        that is originally stored in the circuit by the circuit (IC)        manufacturer;    -   Requires only a very limited trust in the circuit (IC)        manufacturer;    -   No extensive security management is needed in the manufacturing        of the device, and/or between circuit (IC) manufacturer and        device manufacturer;    -   Efficient use of trigger data for enabling generation of        device-specific security data;    -   Possibility to restrict usage of certain functionality in the        circuit to authorized parties.    -   Provision of device-specific security data in combination with        the so-called generic trust delegation protocol or a device        certification structure gives a feasibly implementable solution        to the problem of key management for secure digital rights        management; and    -   Opens up for multi-user identity modules and multi-channel        decoders.

Other advantages will be appreciated upon reading of the belowdescription of example embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram of a general device provided with atamper-resistant electronic circuit according to an example embodiment;

FIG. 2 is a schematic block diagram of an electronic circuit forimplementation in a network device and configured for performing datasecurity operations in network communication based on device-specificsecurity data;

FIG. 3 is a schematic block diagram of an electronic circuit forimplementation in a digital-content producing device and configured forperforming content marking based on device-specific security data;

FIG. 4 is a schematic flow diagram of a method for manufacturing adevice with security data capabilities, including management ofdevice-specific security data, according to an example embodiment;

FIG. 5 is a schematic flow diagram illustrating configuration and usageof trigger data according to an exemplary embodiment;

FIG. 6 is a schematic block diagram of a tamper-resistant electroniccircuit provided with functionality for encrypting configurationalsecurity data into trigger data according to an example embodiment;

FIG. 7 is a schematic block diagram of a particular embodiment of thecircuit of FIG. 6 with further security enhancements using an additionalinput key;

FIG. 8 is a schematic block diagram of a tamper-resistant electroniccircuit provided with device access code functionality for allowingexternal access to generated security data during configuration,according to another an example embodiment;

FIG. 9 is a schematic block diagram of a tamper-resistant electroniccircuit responsive to trigger data for selectively generating anasymmetric key pair/private key according to yet another an exampleembodiment;

FIG. 10 is a schematic block diagram of a particular embodiment of thecircuit of FIG. 9 implemented for generation of private and public keys;

FIG. 11 is a schematic block diagram of an electronic circuitimplemented for shared key generation (e.g. Diffie-Hellman) based ongeneration of private and public keys;

FIG. 12 is a schematic block diagram of an embodiment of an integratedcircuit implemented for generation of private and public keys andprovided with an encryption algorithm for cryptographically protectingthe output private key;

FIG. 13 is a schematic block diagram of an embodiment of an electroniccircuit implemented with an authentication protocol and an associateddevice access code manager/controller;

FIG. 14 is a schematic block diagram of an embodiment of an electroniccircuit provided with functionality for disabling access to secret dataor security data unless the correct device access code is applied to thedevice access code manager/controller;

FIG. 15 is a schematic block diagram of a basic embodiment of anelectronic circuit configured for generation of a chain of bind keys;and

FIG. 16 is a schematic block diagram of another embodiment of anelectronic circuit provided with an iterative implementation forgeneration of a chain of bind keys.

DETAILED DESCRIPTION

Throughout the drawings, the same reference characters will be used forcorresponding or similar elements.

General Overview

FIG. 1 is a schematic block diagram of a general device provided with atamper-resistant electronic circuit according to a basic, preferredembodiment of the invention. The general device 100 includes atamper-resistant electronic circuit 10, and typically also a generalinput/output unit 20 for transferring data to/from the device. Ofcourse, the device may be equipped with additional units, e.g. forperforming various types of data processing, all depending on theparticular device and the overall function thereof.

The tamper-resistant electronic circuit 10 may be an integrated circuit(IC), a smart card or any other tamper-resistant electronic circuit, andpreferably comprises an input/output unit 11, a storage unit 12 for asecret C, an engine or unit 13 for cryptographic processing and apractical realization 14 of a security-related operation. The storedsecret C is not accessible over an external circuit interface and hencenot available outside the electronic circuit 10. The cryptographicengine 13 is connected to the storage unit 12 and configured forperforming cryptographic processing at least partly in response to thestored secret in order to generate an instance of device-specificsecurity data that is internally confined within the electronic circuit10 during usage of the device 100. This generally means that thedevice-specific security data generated by the cryptographic engine 13is not available on the external programming interface of the electroniccircuit during normal usage of the device 100. The security operationunit 14 is linked to the output of the cryptographic engine 13 andconfigured for performing one or more security-related operations inresponse to the internally confined device-specific security data.

It is a great advantage to be able to generate device-specific securitydata and provide full security functionality based on whatever secretdata C that is originally stored in the electronic circuit 10. Thesecurity is uncompromised since the stored secret is never availableoutside the electronic circuit 10, and the internally generateddevice-specific security data can only be used within the circuit toperform a security-related operation during normal operation of thedevice.

The tamper-resistant electronic circuit is generally applicable in awide variety of devices, producing internally confined device-specificsecurity data that can be used for various security-related purposes.Examples of devices suitable for implementing an electronic circuitaccording to the invention include mobile telephones, personalcomputers, cameras, audio devices, network servers, security gateways,firewalls, base stations and so forth.

Network Device Application

As illustrated in FIG. 2, the electronic circuit 10 may for example bearranged in a network device, and the device-specific security datainternally generated by the circuit in operation within the networkdevice 100 can then be used for data security operations in networkcommunication. The network device 100 shown in FIG. 2 generally includesa tamper-resistant electronic circuit 10, a user interface 20-1, and anetwork communication unit 20-2 for communication with other networkdevices or entities in one or more networks. Examples of data securityoperations in network communication include data confidentiality dataintegrity, authentication, authorization and non-repudiation, ascommonly defined, for example in references [4-6]. In anotherapplication scenario, the stored secret C may even be used to generate aterminal address, which is (unique) for the device/terminal and can beused for efficient network communication.

Content-Marking Application

As illustrated in FIG. 3, the electronic circuit 10 may alternatively bearranged in a device 100 that produces digital content such as digitalaudio, video, images, text and so forth. Examples of suchcontent-producing devices include digital photo cameras, video cameras,audio recorders, digital scanners and any digitizing equipmentrepresenting content in digital form. The device-specific security datainternally generated and maintained by the circuit in operation withinthe content-producing device can then be used, e.g. for marking theproduced digital content by generating a device-specific fingerprintembedded into the digital content. This means that content can be tiedto the particular device that actually produced the content, and thefingerprint can later be used as evidence of production. Such a functionbecomes increasingly more important in particular in legal trials sincethe possibility or forging images has become widely spread through theadvanced image processing software available to a low cost. For example,an instance of device-specific security data may be generated eithersolely in response to the stored secret C or in response to the storedsecret in combination with additional input data such as somepredetermined trigger data and/or the content itself. The internallygenerated device-specific security data is then used as input to thesecurity-related operation implemented in unit 14 for embedding adevice-specific fingerprint into the digital content based on thegenerated device-specific security data. The marked content is thenoutput from the electronic circuit 10.

Content-marking may be particularly useful in a combination of a networkdevice and a content-producing device, such as a mobile phone with anintegrated camera, but is also applicable in stand-alone cameras orsimilar imaging, video or audio devices.

Manufacturing Scenario

The following is mainly described with a particular example scenario inmind, namely manufacturing of devices (also sometimes called entities),including management of initial secrets and/or device-specific securitydata, and subsequent usage of such security data within the devices. Itshould though be understood that this scenario is not limiting.

FIG. 4 is a schematic flow diagram of a method for manufacturing adevice with security data capabilities, including management ofdevice-specific security data, according to example embodiment.

In step S1, at circuit manufacturing, a more or less random secret ispreferably stored securely within the tamper-resistant electroniccircuit. This could be implemented in such a way that not even thecircuit or chip manufacturer knows the secret. This secret data may beany arbitrary or randomly generated number. In step S2, which is alsoperformed at circuit manufacturing, the electronic circuit is providedwith cryptographic algorithm(s) implemented for execution in theelectronic circuit with the secret as input or part of the input. Oncethe electronic circuit is installed by the device manufacturer foroperation in a device, the stored secret may be used together with thecryptographic algorithm(s) for generating an instance of security datathat is specific for the particular device in which the electroniccircuit is implemented. The cryptographic algorithmic processing ispreferably based on a cryptographic function designed so that it iscomputationally infeasible to deduce the result of the algorithm withoutknowing the secret, and/or to deduce the secret from the result. In stepS3, a security-related operation is implemented into thetamper-resistant electronic circuit. The operation is configured forusing the device-specific security data as input, and may be related tofor example encryption/decryption, data integrity, authentication,non-repudiation, authorization, and content marking. The electroniccircuit is designed in such a way that device-specific security datagenerated by the cryptographic algorithm(s) during usage of the overalldevice is internally confined within the electronic circuit. This may beaccomplished by using a restricted register within the tamper-resistantelectronic circuit that can only be accessed by the cryptographicalgorithm(s) for write access and the security-related operation forread access during usage of the device. With state-of-the-arttechnology, it is today feasible to store for example 128-bits securitykey in a dedicated hardware register in an integrated circuit.Alternatively, internal confinement is ensured by means of memoryprotection techniques. For example, a protected area in an internalmemory within the electronic circuit may be defined for storage ofdevice-specific security data. Access to this protected area is thenonly allowed from one or more specified memory address areas, in whichthe above-mentioned cryptographic algorithm(s) and security-relatedoperation are maintained in executable form.

Thus, the stored secret and the cryptographic algorithm(s) implementedin the electronic circuit allow generation of securely confineddevice-specific security data, e.g. encryption and decryption keys, bindkeys, symmetric keys, private and associated public keys and/or otherdevice-specific security data, that can only be used for varioussecurity operations within the electronic circuit

In step S4, at device manufacturing, the device manufacturer installsthe circuit in a given device. In step S5, the device manufacturer mayalso be responsible for the general management of device-specificsecurity data and complementary information as generated during anoptional, strictly controlled configuration phase, as will be explainedin detail later on.

In particular, it is clearly advantageous to be able to generatedevice-specific security data and provide full security functionalitybased on whatever secret, random data that is originally stored in theelectronic circuit by the circuit manufacturer. Furthermore, theelectronic circuit allows generation and management of device-specificsecurity data for a wide range of devices in which the circuit may bearranged. In addition, since the secret data is securely stored in thecircuit, there is no need for any extensive security management in themanufacturing of the device or in the distribution of circuits betweenthe circuit manufacturer and the device manufacturer.

In fact, very limited security management is required between circuitmanufacturer and device manufacturer. The particular value of C isnormally not relevant as long as it remains unknown to unauthorizedparties, especially if no one knows or has access to C. It suffices thatthe stored secret C is sufficiently random over a sufficiently large setand impossible to link to the particular circuit. Since it is notnecessary to record or derive information from C during circuitmanufacturing, this can effectively be implemented within a controlledenvironment at the circuit manufacturer.

If desired or otherwise appropriate, additional security managementbetween circuit manufacturer and device manufacturer can however beobtained by implementing, into the circuit, public key encryption (e.g.RSA encryption) of the secret C based on the public key of the devicemanufacturer, where the public key is stored in the circuit, andoutputting the encrypted secret. The encrypted output can only bedecrypted by the device manufacturer using the corresponding privatekey. In this way, C will be known to device manufacturer.

As will be described later on, the invention is also well adapted foradditional security management of the device-specific security data,e.g. certification and trust delegation, in order to enable trustedthird parties to communicate securely with the network device and/oruser.

The type of security management that is appropriate depends on theparticular threats or attacks that the system is required to beresistant against and also what parties in the system that to someextent are trusted. For example, management of security data for networkdevices is a very important task, since the security of the entirecommunication may rely upon it.

Accordingly, the parties authorized with device-specific security datamay be different for different instances of the described problem. It isassumed throughout the following examples that the device manufactureris trusted with the device-specific security data, though the technologyis not limited to that assumption. As indicated above, the chipmanufacturer does not need to be trusted with the security data, thoughsome sort of trust relation is normally assumed, e.g. that the chipmanufacturer implements what is agreed upon and introduces no secret“back-doors” and so forth. It is also common that the device owner oruser is considered a trusted party, since it usually is in his/herinterest to ensure that message transfer is secure. However, this is notnecessarily true and will not be assumed; a particular exemptionscenario is that of DRM.

Digital Rights Management (DRM), for example, is a technology forprotecting a content provider/owner's assets in a digital contentdistribution system. The technology is in most cases implemented byencrypting the content, and associating to this content a so-calledlicense that includes the decryption key (normally in encrypted form),and usage rights describing what is allowed to do with the content.

In the equipment that will be used for rendering the content, a DRMmodule/agent is implemented to ensure that the rendering follows what isprescribed by the usage rights. This agent is typically implemented as asoftware and/or hardware module, enforcing the usage policy as stated inthe license. The DRM module/agent constitutes the trusted party withinthe user equipment, from the point of view of the content provider. Notethat the user is not a trusted party, since the user may want tocircumvent the content protection and use the content without therestrictions prescribed in the license.

The problem of securing the content is partly to manage theconfidentiality of the content and the integrity of the license duringtransport from the content distributor to the device where the contentwill be used. A possible solution to this problem is for the contentprovider/distributor to securely deliver to the DRM module/agent in therendering equipment a “key encryption key”, which can be used to derivethe content encryption key and check the license integrity. To protectthe key encryption key, device security data, unavailable to the user,could be used by the DRM module/agent. Also some information related tothis security data is needed by the trusted content provider/distributorto secure the transfer to this particular device. For example, if thesecurity data is a decryption key, the corresponding encryption key isnormally needed by the content distributor/provider.

Trigger Data—Configuration vs. Usage

With reference once again to FIG. 1, the stored secret C may be the soleinput to the cryptographic engine. Alternatively, however, additionalinput may be applied via the input/output unit 11 of the electroniccircuit 10 and used together with the stored secret C in thecryptographic engine 13 to generate the device-specific security data.In an embodiment, optional trigger data (indicated by the dashed line inFIG. 1) required for generating proper security data is defined duringconfiguration of the device 100, for example in a configuration phaseduring manufacturing or during user configuration depending on theparticular application.

During later usage of the device 100, the same trigger data has to beapplied to the electronic circuit 10 into the cryptographic engine 13 tobe able to generate the device-specific security data.

As schematically illustrated in the basic flow diagram of FIG. 5,trigger data is determined during configuration of the device, perhapsin a configuration phase during manufacturing of the device or duringuser configuration (S11), as will be exemplified later on. Duringsubsequent usage, internally confined device-specific security data isgenerated provided that the same trigger data is applied over anexternal circuit interface. In other words, both the stored secret C andthe predetermined trigger data are required in order to be able togenerate proper security data (S12). Finally, a security-relatedoperation is performed in response to the internally generated andinternally confined device-specific security data (S13). If the triggerdata is defined during manufacturing of the device, the trigger data mayhave to be securely transferred from the device manufacturer to thedevice, for example via an intermediate trusted party such as a networkoperator to which the user of the device is associated.

Alternatively, the predetermined trigger data is stored in the devicefor easy access when the device-specific security data needs to beinvoked for a security-related operation. In some applications, theadditional input data may even be publicly known information, since onlythe owner of the device comprising the particular circuit is able togenerate the result due to the stored secret involved. This means thatan adversary with physical access to the device, may possibly gainaccess to the trigger data or code to perform the security-relatedoperation. However, the adversary will never gain access to thedevice-specific security data itself, which is always internallyconfined within the circuit during usage of the overall device. In someapplications, it may be advantageous to protect the stored trigger code,e.g. by means of a user-selected password.

Multiple Triggers

It is also fully possible to define multiple individual trigger datasignals during configuration of the device, where each trigger datasignal is associated with a respective individual device-specificsecurity data. The electronic circuit according to the invention is thenconfigured for generating a particular device-specific security dataprovided that the associated trigger data signal is applied to thecircuit. This may be utilized for providing a multi-user identitymodule, such as a multi-user SIM (Subscriber Identity Module) forauthentication and key agreement purposes, or a multi-channel decoder,such as a satellite or cable TV decoder, where several unique securitykeys are required. A certain key is simply activated by applying thecorresponding trigger data.

In general, trigger data may be defined in several ways. By way ofexample, the trigger data may be defined based on configurationaldevice-specific security data provided during configuration of thedevice, as will be described below mainly with reference to FIGS. 6 and7. The trigger data may also be a simple seed initially applied to theelectronic circuit during configuration of the device, forcing theelectronic circuit to output device-specific security data over anexternal circuit interface in response to a so-called device accesscode, as will be outlined mainly with reference to FIG. 8.Alternatively, for applications based on asymmetric cryptography,suitable additional input such as a prime, a generator of a mathematicalgroup, a nonce and/or a PIN code may be used as trigger data, as will bedescribed below with reference to FIGS. 9-12.

Encryption/Decryption of Configurational Security Data

FIG. 6 is a schematic block diagram of a tamper-resistant electroniccircuit provided with functionality for encrypting configurationalsecurity data into trigger data according to an example embodiment.Preferably, the electronic circuit 10 is configured for generatingtrigger data as a cryptographic representation of some configurationaldevice-specific security data, based on the stored secret. Thecryptographic representation is then output over an external circuitinterface during the configuration phase. During usage of the device,the device-specific security data is internally re-generated providedthat said additional input corresponds to the cryptographicrepresentation. This allows the device manufacturer or other trustedparty in control of the devices, such as a network operator, to freelyselect device-specific security data for manufactured devices duringdevice configuration. This may be advantageous in certain applicationswhere the security data is requited to have a particular format. Forexample, in asymmetric cryptography such as RSA or elliptic curves, thekeys are not just random strings but rather have to be chosen withcaution.

In addition to the random secret C implemented by the circuitmanufacturer in the storage unit 12, the electronic circuit 10 includesa practical realization 15 of a trapdoor one-way function, in this caserepresented as an encryption algorithm E using the secret C asencryption key. The electronic circuit 10 also includes a practicalrealization 13 of the corresponding trapdoor inverse algorithm, in thiscase performing decryption D, as well as a realization 14 of asecurity-related operation.

During configuration, the device manufacturer or other configuring partygenerates any desired device-specific security data K, e.g. acryptographic key, and applies this to the circuit 10 for encryption. Itshould be understood that the configuration does not necessarily have tobe performed during manufacturing, but may be performed later, forexample by the device manufacturer in a separate configuration phase orby a separate party, such as a network operator, in control of themanufactured devices. The cryptographic result representation E(C, K)=Xis recorded by the device manufacturer or other configuring party in acontrolled environment and optionally stored in the device. The thusgenerated pair (X, K) can for example be used later by the configuringparty or a trusted third party to communicate securely with the device.If appropriate, considering the trust model, the result representation Xand/or the corresponding configurational security data K can be managedby a trusted network operator. The result representation X may besecurely transferred from the operator to the device, such as a mobiletelephone or similar network device associated with the operator, basedon a session key obtained from an authentication and key agreementprocedure.

Alternatively, the cryptographic representation X is stored in thedevice already during configuration. Unless K is internally confinedduring usage of the device, an adversary with access to the device andthe stored trigger data X may get hold of the device key K. Therefore,the internally generated device key K is never displayed outside thecircuit during usage of the device, but only used within the circuit forwhatever security operation or operations that are required. This meansthat the cryptographic representation X can be stored, for example in aPROM in the device and at the same time the sensitive device key K willresist attacks from an adversary with access to the device and to theprogramming interface of the electronic circuit. Optionally, if thetrust model so admits, X may even be protected by the user, so thatauthentication by means of a password or PIN must be carried out to beable to retrieve X for input into the electronic circuit, optionallytogether with a limited number of trials before a special authenticationcode is necessary.

In summary, the circuit illustrated in FIG. 6 involves several layers ofoperations in two different phases: During a configuration phase,configurational data in the form of a device key K is encrypted withalgorithm E. Later on, during usage of the device, the encrypted resultrepresentation is decrypted with algorithm D, and the resulting devicekey instance is then used as input to the security-related operation,such as decryption of encrypted information into clear text, data originauthentication, message integrity protection or a combination of suchsecurity operations, as is clear to anyone familiar with the field.Optionally, the operation D could incorporate non-cryptographicsecurity-related functionality that is sensitive with respect to thetrust model, e.g. management of data that should be available only forauthorized parties and therefore remain within the circuit. DRM lends aparticular example to this where high quality clear text content (suchas text, audio and video) may be required to remain confidential, thougha lower resolution copy is allowed to reach the rendering device.

Thus, the security-related operation could be configured for selectivelyreducing the resolution or selectively performing D/A conversion and soforth controlled based on information relating to the device key K.

Naturally, the above procedure can be extended to multiple pairs (K, X)and/or multiple secrets C. Again, the actual value of C is not generallyrelevant as long as it is not known by any unauthorized party.

It should also be understood that is possible to internally generate theconfigurational security data in the electronic circuit during theconfiguration phase, as will be explained later on in connection withFIG. 12.

FIG. 7 is a schematic block diagram of a particular embodiment of thecircuit of FIG. 6 with further security enhancements using an additionalinput key. In order to further enhance the security of thetamper-resistant electronic circuit of FIG. 6, an additional input keymay be employed as is illustrated in FIG. 7. Similarly to FIG. 6, duringconfiguration, e.g. at manufacturing, the device manufacturer or otherconfiguring party uses the algorithm E implemented in unit 15 and key Cto encrypt security data K1. The obtained encrypted output X1 may bestored in the device during configuration or otherwise transferredsecurely to the device and subsequently input to the associateddecryption algorithm D1 implemented in unit 13. Additional security dataI2 could also be generated and internally confined within the electroniccircuit 10. An encrypted representation X2 of security data K2 ispreferably provided to the device for use as input to the electroniccircuit 10. K2 may initially be generated by the device manufacturer orother configuring party, e.g. in connection with the encryption of K1.Alternatively, K2 may initially be generated by a third party, e.g. acontent provider or distributor, which wants to securely distributedigital data to the device. In such a case, the content providerrepresents K2 as X2 in such a way that internal access to K1 isnecessary for internally reproducing K2, e.g. if K1 is a private keythen X2 is the corresponding public key encryption of the key K2. Theprivate key could be a private key of the device manufacturer and doesnot have to be known by the user. The public key could be available,e.g. from a Certificate Authority of a Public Key Infrastructure. Thecontent provider then distributes X2 to the device. An associateddecryption algorithm D2 is implemented in unit 14-1 in the electroniccircuit for decrypting the received encrypted input X2 by means of theinternally generated K1. Decryption of data (or other securityoperation) received from the device manufacturer or a third party, e.g.the content provider, based on the security algorithm D′ implemented inunit 14-2 is available by entering X1 and X2 and the received data, cip,into the relevant circuit interface to obtain the clear text cle.

Selectively Allowing External Access to Security Data duringConfiguration

FIG. 8 is a schematic block diagram of a tamper-resistant electroniccircuit provided with device access code functionality for allowingexternal access to generated security data during configuration,according to another preferred embodiment of the invention. Aspreviously mentioned, the trigger data may alternatively be a simpleseed, such as a nonce, a bind identity or similar data, which isinitially applied to the electronic circuit during configuration of thedevice for generating device-specific security data B based on thestored secret C and the input trigger data R. For example, R may be arandom bit string and/or some unique device identity. The cryptographicengine 13 is preferably implemented with an approximation of acryptographic one-way function fusing the secret C and the trigger dataR as input. For example, the cryptographic one-way function could be akeyed MAC (Message Authentication Code), see [7, 8], of the input data Rusing C as the key.

In addition to the basic storage unit 12 for the maintaining the secretC, the cryptographic engine 13 and the security-related operation 14,the tamper-resistant electronic circuit 10 shown in FIG. 8 alsocomprises a controller 16 and a switch arrangement 17 for selectivelyforcing the electronic circuit to output the device-specific securitydata B over an external circuit interface during configuration. Thecontroller 16 preferably operates in response to a so-called deviceaccess code (DAC), and closes the switch 17 for making thedevice-specific security data B available outside the circuit when theDAC is applied to the circuit during the configuration phase. Forexample, the DAC may be given to the device manufacturer or otherconfiguring party by the circuit manufacturer in an authorizationprocedure, as will be described in detail later on. If the correct DACis not entered during configuration, the switch 17 remains open and thedevice-specific security data B is only available on appropriateinternal interfaces, and consequently never leaves the electroniccircuit 10. After configuration, it may even be desirable to disable thecontroller 16 to ensure that an adversary with physical access to thedevice can not attack the circuit 10 by testing different codes in anattempt to get hold of the device-specific security data.

For example, the configuration may be performed during manufacturing,where the device manufacturer inserts the electronic circuit such as anIC received from an IC manufacturer into a particular device. By usingthe implemented cryptographic function f, device-specific security datacan be obtained: In a controlled environment, the device manufacturerenters some data R as input to the algorithm implemented in thecryptographic engine in the circuit to generate the result f(C, R)=B,and also applies a predetermined DAC to the controller 16 to enableexternal output of the resulting security data B.

In the example of FIG. 8, the device manufacturer or other configuringparty is generally not able to choose device-specific security data buthas to accept whatever comes out of the one-way function f, whereas inthe examples of FIGS. 6 and 7, the configuring party is free to selectthe device-specific security data.

The pair (R, B) may be used later, e.g. after the device has been soldto a user, by the device manufacturer or other configuring party, oreven a third party trusted by the device configurer to communicatesecurely with the device. The device-specific security data B can beused to secure the communication, e.g. as a cryptographic key in asymmetric encryption algorithm or in a message authentication code.During usage, the trigger data R is required by the device to internallyrecreate B in the electronic circuit 10. For example, if R is equal to aRAND in a key agreement procedure such as GSM AKA (Authentication andKey Agreement) or UMTS AKA, the resulting device-specific security datawill be an AKA session key.

The trigger data R can be stored in the device during manufacturingand/or configuration, or supplied prior to establishment of the securecommunication. Although high confidentiality is preferred, the triggerdata R does not necessarily need to be kept confidential since only withaccess to the right electronic circuit, the relevant security data B canbe produced, and during usage of the device, the security data B neverleaves the circuit. However R is preferably integrity protected, e.g.with B or by some out-of-band mechanism, to protect from e.g.disturbances in communication, manipulation and/or denial-of-serviceattacks.

An example of a particular application could be a companyowning/managing a number of network nodes communicating over an unsecurenetwork. For example, the nodes/devices could be radio base stations ina mobile network, electricity consumption metering devices, automaticdrink/food resales machines, all provided with electronic circuits withthe general structure of FIG. 8. During configuration of the nodes bythe trusted staff of the company, a number of node-specific keys B aregenerated by the manufacturer in response to one or more input numbersR, using one or more DACs to extract the security data from thecircuits. During usage, the input number(s) R is distributed (preferablyintegrity protected) to the network nodes (or stored therein duringmanufacturing/configuration), and input to the corresponding electroniccircuits to generate the node-specific key(s) B. Once the secret key(s)B is/are securely shared between the involved nodes, securecommunication can be established by means of any conventionalcryptographic protocol using B.

Multiple pairs (R, B) may be generated and/or multiple secrets C may beimplemented, e.g. to enable revocation of certain security data or todifferentiate between communications parties.

In another particular example, the pair (R, B) may constitute abind-identity-bind-key pair. An example of delegation of trust involvinggeneration of bind-identity-bind-key pairs is a protocol called theGeneric Trust Delegation (GTD) protocol. It may be useful to give anoverview of the basics of the GTD protocol. The mechanism forestablishment and delegation of trust in the GTD protocol is based onthe assumption that two parties P1, typically a device manufacturer, andP2, typically an associated device, share a (symmetric) secret. Theprotocol takes advantage of the fact that the device manufacturer P1normally has assigned a secret device key to the device P2, which devicekey is properly protected in the device. A third party P3, having atrust relation with P1, wants to communicate securely with P2. As a maincomponent, the GTD protocol includes a basic request-reply protocol, inwhich P3 requests, from P1, a bind key for secure communication with P2.The party P1 generates a bind identity, unique for the pair P2 and P3.Then, party P1 derives a bind key based on the bind identity and thesecret that P1 share with P2, preferably by using a cryptographicone-way function. The bind key, normally together with the bindidentity, is sent securely from P1 to P3 (the security is based on keysderived from the existing trust relation between P1 and P3). Since P2knows the shared secret between P1 and P2, the party P2 can alsocalculate the same bind key given the above bind identity. The latter isgenerally not confidential and may be sent to P2 from P1 or P3.Accordingly, P2 and P3 can then communicate securely using the bind key.Naturally, instead of the device-specific key itself, another keyderived therefrom could be used on both sides for calculating the bindkey. In this procedure, P1 thus “delegates trust” to P3 in the form ofthe bind key between P2 and P3.

The device manufacturer never has to reveal the device-specific key (ormore generally the entity key) to any other party, since there is noneed to transfer the device-specific key outside of the device and thedevice manufacturer (or other device configurer). In addition, the GTDprotocol does not require a single third party trusted by all devicemanufacturers.

The unknown secret never has to leave the domain of the manufacturer,except in the protected area within the electronic circuit of the devicewhere the (circuit) manufacturer stored the secret during manufacturing.The manufacturer thus has more possibilities and all incentives to keepthe secret confidential, compared to the prior art.

Generating Private Key and/or Asymmetric Key Pair

FIG. 9 is a schematic block diagram of a tamper-resistant electroniccircuit responsive to trigger data for selectively generating a privatekey/an asymmetric key pair according to yet another embodiment. In FIG.9, suitable additional input such as a prime, a generator of amathematical group, a nonce and/or a PIN code may be applied to thecircuit during configuration of the device, either during aconfiguration phase in manufacturing or during user configuration, forgenerating an asymmetric key pair (A, P.sub.A) and for outputting thepublic key P.sub.A over an external circuit interface. During usage ofthe device, the corresponding private key A is internally re-generatedprovided that at least part of the same additional input is applied astrigger data over an external circuit interface. The internallygenerated private key A may then be used for PKI (Public KeyInfrastructure) operations such as encryption/decryption andauthentication.

FIG. 10 is a schematic block diagram of a particular embodiment of thecircuit of FIG. 9 implemented for generation of private and public keys.In the following, we consider the exemplary case of cryptography basedon discrete logarithms. As an example, it is possible to use thediscrete logarithm problem over the multiplicative group of integersmodulo a large prime P with generator G. An integer chosen at randomfrom 1, . . . , P-2 can be used as a private key. As illustrated in FIG.10, we will designate this number A, which may be identical to theunknown chip secret number C or derived from the chip secret togetherwith optional input. As before, the number A is hidden within theelectronic circuit and should not be possible to extract, nor any(except negligible) information of A.

The cryptographic engine 13 is based on a general function Z forgenerating key A based at least on the secret C. A large prime P couldoptionally be input to the engine 13, which then have to generate asuitable A. Also generator G could be input, but the circuit should thenpreferably check if G is a generator of the group. A nonce generatede.g. by the device manufacturer may also optionally be input to thecircuit for use in the generation of the key A.

It should also be possible to generate and output a corresponding publickey P_(A) from the circuit, this could e.g. be G^(A) mod P and/or otherinformation such as G or P. The cryptographic engine 13 then alsoinclude a general function Y for generating this public key P_(A),preferably based on P, G and A. The public key should be distributed inan authenticated manner to the relevant communications partner so thatit can be used securely, more of which will be described later. Theelectronic circuit 10 can perform one or more public key operations D′such as e.g. encryption or digital signature functions based on theprivate key A. Specific examples are ElGamal encryption and ElGamalsignature.

The unknown secret C is easily generated and stored in the circuit 10(e.g. IC) during circuit manufacturing, and with the new functionalityshown in FIG. 10, it is thus possible to generate an asymmetric key pairthat can be used by the device in which the IC is arranged for securecommunication.

Another usage of this public-private key pair is shared key generation,as schematically illustrated in FIG. 11. For example, for Diffie-Hellmanshared key generation, the device public key P_(A)=G^(A) mod P isexchanged for the communications partner public key P_(B)=G^(B) mod P,where B is the corresponding private key. P_(B) is fed into a shared keygeneration unit 14-3 in the circuit 10 and the shared secret G^(AB) modP is calculated. An optional random nonce may be also used in analgorithm together with the shared secret to guarantee freshness andrestrict the leaking of information of the private keys. The result is ashared secret key K_(AB), which is not externally available. Theestablished key can then be used for a security-related operation D′such as conversion of encrypted information CIP into clear text outputCLE, as implemented in unit 14-2.

More generally, if A is a private key with corresponding public keyP_(A) in an asymmetric cryptographic scheme, with A protected within atamper-resistant electronic circuit, the invention also covers the casethat a symmetric cryptographic key K, encrypted by the public key P_(A),is decrypted and used within the circuit, and not exposed outside thecircuit, in analogy to the previous examples.

Depending on usage, the private key may be used as a device key.Optionally, the corresponding public key may be certified by the devicemanufacturer, as will be exemplified later on.

In an alternative embodiment, the user generates a private key, notnecessarily directly derived from the chip secret. For example, thecryptographic engine 13 may be implemented with a pseudo-random numbergenerator, which using the chip secret as seed could be iterated anumber of times, possibly with some additional input to generate aprivate key. As in previous examples, the private key may be hiddenwithin the electronic circuit and the corresponding public key availableoutside.

Optionally, an additional nonce may be inserted by the user duringgeneration of the key. Alternatively, or as a complement, a PIN(Personal Identification Number) or a password mapped to a number may bethe nonce or part of the nonce to enable user authentication in thesense that the PIN or password is necessary to produce the private keyinside the circuit.

Yet another option that can be used in conjunction with the methodsabove is to encrypt the private key, generated as in one of the casesabove, with encryption algorithm E and chip secret C′ and output theencrypted private key X, as illustrated in FIG. 12. In similarity to theembodiments of FIGS. 9-11, the tamper-resistant electronic circuit 10shown in FIG. 12 includes a storage unit 12-1, a cryptographic engine 13for generating an asymmetric key pair, and a security-related operation14. In addition, however, the circuit 10 in FIG. 12 also includes anencryption unit 15 implementing algorithm E, a further storage unit 12-2for an additional secret C′ and a decryption unit 13-2 for decrypting anencrypted private key. This is actually a hybrid of the realization ofFIG. 9 or FIG. 10 and the realization of FIG. 6, but where the so-calledconfigurational device-specific key, here the private key A, isinternally generated in response to optional input data and subsequentlyencrypted into a result representation X. When the private key needs tobe used within the electronic circuit during usage of the overalldevice, X is inserted into decryption unit 13-2 via a special interfaceand then decrypted by D based on C′. The internally generated privatekey A can subsequently be used in algorithm D′. Optionally, X may bepassword protected or require other user authentication.

Although the realizations illustrated in FIGS. 10-12 are based ondiscrete logarithms, it should be understood that other schemes forgenerating an asymmetric key pair are also feasible.

Authorizing the Use of Circuit Capabilities

As previously mentioned briefly, it might be in the circuitmanufacturer's interest to enforce that the device manufacturer or otherconfiguring party can only utilize the tamper-resistant electroniccircuit when so being authorized by the circuit manufacturer. Also oralternatively, depending on the trust model, the device manufacturer candesire to authorize which (further) parties (if any) that should haveaccess to capabilities of the electronic circuit. This can be achievedby “conditioning” certain operations within the electronic circuit,based on an authentication process. Such operations could be, e.g.access to the value C for certain algorithms, and even output of certainvalues, possibly also including C, from the circuit. The authenticationprocess could be a simple maintenance/user password, but preferablyinvolves a secure authentication mechanism such as the Fiat-Shamirprotocol [9] or other zero-knowledge protocol.

FIG. 13 is a schematic block diagram of an embodiment of an electroniccircuit implemented with an authentication protocol and an associateddevice access code (DAC) manager/controller. For simplicity, only thoseparts of the circuit that are relevant to the authentication and deviceaccess code are illustrated in FIG. 13. We now give an example of anauthentication procedure for providing a device access code. Preferably,an authentication protocol 18 such as the Fiat-Shamir protocol isimplemented in the electronic circuit 10. This enables the electroniccircuit 10 to authenticate the device manufacturer or other configuringparty based on a public key PK implemented in the circuit 10. The devicemanufacturer or other configuring party utilizes a programming station110 to transfer information signed by a private key SK to the electroniccircuit 10 for verification in the authentication protocol unit 18 basedon the corresponding public key PK. This apparently implies that thepublic key PK has to be entered into the electronic circuit 10 alreadyduring circuit manufacturing. The device manufacturer or otherconfiguring party typically produces asymmetric key pairs (SK, PK) andprovides the circuit manufacturer with a public key PK or a list of suchpublic keys. The public key is of course public information and requiresno additional security management. Additionally, the electronic circuit10 is also provided with a DAC manager/controller 16. A challenge R isentered into the DAC manager 16 from the programming station 110. Forexample, R may be a random number, contain information of the deviceidentity or be a hash value of such information. If the precedingauthentication was successful, as indicated by a signal from theauthentication protocol unit 18, the DAC manager 16 generates a responseS, e.g. by employing a MAC function. The response S is then transferredby the electronic circuit 10 to the programming station 110. The pair(R, S) constitutes a device access code, DAC, which subsequently can beused by the authorized party to get access to certain circuitcapabilities. For example, the DAC can be used by the devicemanufacturer or other configuring party to make device-specific securitydata available on an external circuit interface during deviceconfiguration, as previously exemplified in FIG. 8.

Given the appropriate trust model, the device manufacturer for examplemay give/license the DAC to a trusted third party. The DAC may also beused to “re-program” the device, for example replacing compromisedsecurity data with new.

As illustrated in FIG. 14, the electronic circuit may also be configuredfor disabling internal access to the stored secret and/or thedevice-specific security data, unless a predetermined device access codeDAC is entered into the electronic circuit. For example, this can beachieved by arranging a switch in the signal path from the storage unit12 to the cryptographic engine 13 and/or in the signal path from thecryptographic engine 13 to the security-related operation 14. Theswitches are typically controlled by a DAC manager/controller 16, whichoperates in response to a device access code (R, S). For example, theDAC manager 16 could map the received R value into an expected responseS′ by calculating keyed MAC:S′=MAC(R, C),and then compare the received response S to the calculated expectedresponse S′ to verify the device access code (R, S). By default, theswitch or switches are open disabling access to the circuitcapabilities. Once the correct device access code is entered andverified, the DAC manager/controller 16 closes the switch or switches toenable access to the circuit capabilities.

In this way, it can be ensured that only an authorized party, such asthe device manufacturer and/or other party trusted with the deviceaccess code, is allowed to use the stored secret for generation ofdevice-specific security data and/or use the security data itself.

The above mechanisms for providing conditional access to circuitcapabilities upon authentication are general features of the inventionand can be applied to any of the examples given in the presentapplication.

Hierarchy of Bind Keys

The GTD protocol disclosed above can also be iteratively applied,resulting in a chain of shared bind keys. The basic GTD protocol startswith two parties sharing a secret key and ends with one of the initialparties sharing another secret key with a third party. The procedurecould be repeated iteratively, involving a fourth party that will, afterthe second application of the protocol, have a shared secret key withone of the previous parties, and so on for higher order iterates.

It has been recognized that also the iterated GTD protocol could beimplemented entirely within a tamper-resistant electronic circuit, asillustrated in FIG. 15. The cryptographic engine 13 now includesmultiple instances of a cryptographic one-way function, f, for producinga chain of k bind keys B₁, . . . , B_(k) in response to correspondingbind identities R₁, . . . , R_(k) according to the following formula:B _(i) =f(B _(i-1) , R _(i)) for i=1, . . . , k,where B₀=C.

The first bind key B₁ is typically deduced by the device manufacturer orother configuring party during configuration of the device, for examplein a configuration phase during manufacturing, by entering the correctdevice access code DAC into the DAC controller 16. Once the correct DACis verified by the controller 16, the switch 17 is closed to enableoutput of the first bind key B₁ outside of the electronic circuit 10. Ifthe correct DAC is not entered, the bind key is unavailable outside thecircuit.

By supplying a sequence of bind identities, the device can subsequentlycalculate the corresponding bind keys and finally perform a securityoperation, such as decryption of encrypted data CIP into clear textoutput CLE by means of a decryption algorithm D′. The bind keys areinternally confined within the circuit 10, and can not be transferredover an external IC interface by a third party that does not know thedevice access code. With this implementation an attacker, with physicalaccess to the device, will at most be able to decrypt a given encryptedmessage, but not get access to the actual bind keys.

Thus we have established, without any security management betweencircuit manufacturer and device manufacturer, a whole set ofdevice-specific keys (B_(i), i=1, . . . , k) that are available onlywithin the electronic circuit.

In the realization of FIG. 15, the bind identities R₁, . . . , R_(k) areinserted “in parallel”. Alternatively, the bind keys may be generated byan “iterative” implementation, as schematically illustrated in FIG. 16.In the example of FIG. 16, the bind identities R₁, . . . , R_(k),together with a number k indicating the number of required iterations,are inserted “in serial”, e.g. concatenated onto an IC input interface.A built-in algorithm within the electronic circuit 10 then iterates thefunction f as many times as indicated by the inserted number k,successively processing the relevant inputs (B_(i)=f(B_(i-1), R_(i)) fori=1, . . . , k and where B₀=C) to output B_(k) to operation D′ or anyother suitable security-related operation or algorithm. With thismodification, any intermediate bind key can be generated for protectedusage with D′. As before, a DAC may be entered to provide externalaccess to the initial bind key.

Managing Security Data to Include Trusted Third Party

In the following, we will focus some more on how to handle securitymanagement if a trusted third party wants to communicate securely withthe device with or without a user being involved/trusted.

The user being involved/trusted is a common scenario and needs nofurther explanation. In the DRM setting, however, the user is nottrusted as we described previously. In other settings, there may not bea user during normal operation e.g. if the device runs stand-alone. Inall cases involving a third party, the third party must access someinformation to be able to ensure secure communication with the intendeddevice. This information may e.g. be a symmetric key to a device vouchedfor by a trusted and authorized party or a device-manufacturer-signeddevice public key certificate used to authenticate a communicationentity. We outline two examples in more detail below.

Symmetric Key Delegation to Third Party

Consider the example of FIG. 8. As a particular instance, (R, B) couldbe a “bind identity”—“bind key” pair, simply referred to as a “bindpair”, as in the basic GTD protocol. Thus, one or several bind pairs aregenerated during configuration, e.g. at device manufacturing, and storedby the configuring party such as the device manufacturer. By anout-of-band arrangement, a trusted third party is in a secure mannerdelegated one or several bind pairs of this particular device and canthen communicate securely with the device, by referring/supplying thebind identities.

The iterated GTD protocol could be achieved analogously to allow atrusted party to further delegate trust to parties that can communicatesecurely with the device.

Alternatively, a chosen symmetric key K can be used as described inconnection with FIG. 6, and the pair (X, K) can be used in the same wayas (R, B) above to allow trusted third parties to set up a securechannel to a device.

Public Key Infrastructure

Consider once again the structure exemplified in FIG. 6. Now, assumethat K is an asymmetric cryptographic key, e.g. a private key. Thefollowing operations could be carried out in a particular securelocation, e.g. at the device manufacturer during manufacturing:

A private device decryption key K may be generated together with apublic encryption key certificate signed by the device manufacturer'sprivate signature key. The latter key also has a corresponding publickey certificate signed by a trusted party, such as a CertificationAuthority (CA) of a Public Key Infrastructure (PKI), and available for arelevant party to access, see [8]. The key K is fed into the electroniccircuit to produce the corresponding X, which may be stored in thedevice. Subsequently, the private key K may be completely erased at thedevice manufacturer's domain to prevent any unauthorized usage. Thepublic encryption key certificate may be placed in a publicly availablecertificate repository. Anyone with access to the public key can laterperform encryption of data pertaining to this device. The privatedecryption key only exists for a short moment in the electronic circuit.

The situation is completely analogous for digital signatures, replacing“decryption” with “signature”, and “encryption” with “verification” inthe paragraph above, as is known by anyone familiar with the subject.

A similar procedure applies to the realizations described in connectionwith FIGS. 9-12. There, a private key is already available or generatedwithin the electronic circuit and the corresponding public key isrevealed outside the circuit. Thus, the device manufacturer or the usercan certify/request certification of this public key and then a thirdparty may use the certificate to enable the desired security operations.

The embodiments described above are merely given as examples, and itshould be understood that the present invention is not limited thereto.Further modifications, changes and improvements that retain the basicunderlying principles disclosed and claimed herein are within the scopeof the invention.

REFERENCES

-   [1] European Patent Application 0 753 816 A1, published Jan. 15,    1997.-   [2] U.S. Pat. No. 6,141,756 issued Oct. 31, 2000.-   [3] Digital Signature Cards Range—Secure smart cards for doing    electronic business, GEMPLUS, printed on Oct. 27, 2003 from    http://www.gemplus.com/products/dig_sign_cards_range.-   [4] How PKI can reduce the risks associated with e-business    transactions, by Cannady and Stockton, IBM, Feb. 1, 2001.-   [5] The mechanisms of data security, printed on Sep. 2, 2003 from    http://www.cardsnowindia.com/news/security1.htm.-   [6] Security in an open world, Skillteam, printed on Sep. 2, 2003    from http://www.common.lu.-   [7] HMAC, Keyed-Hashing for Message Authentication, RFC 2104 by    IETF.-   [8] Handbook of Applied Cryptography, Menezes, van Oorschot, and    Vanstone, Chapters 1, 9 and 12, CRC Press.-   [9] U.S. Pat. No. 4,748,668 issued May 31, 1988.

1. A tamper-resistant electronic circuit for implementation in a device,said tamper-resistant electronic circuit comprising: a storage devicefor tamper-resistantly storing, during manufacture of thetamper-resistant electronic circuit, a random secret not accessible overany external circuit interface to the tamper-resistant electroniccircuit and unknown after being stored in the storage device; triggerdata generating circuitry for, during configuration of thetamper-resistant electronic circuit, generating trigger data bycryptographically combining the random secret and device-specificsecurity data that is different from the random secret and outputtingthe trigger data outside of the tamper-resistant electronic circuit; areceiver for, during operation of the configured tamper-resistantelectronic circuit by a user, receiving external to the tamper-resistantelectronic circuit from the user via an external circuit interface thetrigger data; a cryptographic processing engine, in response to theexternally received trigger data from the user, for performingcryptographic processing at least partly in response to said storedsecret and the externally received trigger data from the user togenerate a temporarily available instance of the device-specificsecurity data internally confined within said electronic circuit duringusage of said device and such that the temporarily available instance ofthe device-specific security data is only available when the externallyreceived trigger data is received; and electronic circuitry, connectedto the cryptographic processing engine and configured to perform asecurity-related operation in response to said internally-confined,temporarily available instance of device-specific security data.
 2. Theelectronic circuit according to claim 1, wherein said device is anetwork device and said operation is related to at least one of dataconfidentiality, data integrity, authentication, authorization andnon-repudiation in network communication.
 3. The electronic circuitaccording to claim 1, wherein said device is configured for producingdigital content and said security-related operation is configured formarking said digital content based on said internally-confined,temporarily available instance of device-specific security data.
 4. Theelectronic circuit according to claim 3, wherein said operation isconfigured for generating a device-specific fingerprint embedded intosaid digital content.
 5. The electronic circuit according to claim 1,said electronic circuit is configured to: generate, based on said storedsecret and said configurational device- specific security data, saidtrigger data as a cryptographic representation of said configurationaldevice-specific security data during configuration of said device;output said cryptographic representation over an external circuitinterface during configuration; and re-generate said device-specificsecurity data during usage of said device provided that said additionalinput corresponds to said cryptographic representation.
 6. Theelectronic circuit according to claim 5, wherein said internallyre-generating said device-specific security data comprises generating aprivate key at least partly based on said stored secret, and saidtrigger data is generated as a cryptographic representation of saidprivate key during configuration of said device.
 7. The electroniccircuit according to claim 1, further configured to make, duringconfiguration of said device, said internally-confined, temporarilyavailable instance of device-specific security data available over theexternal circuit interface provided that a predetermined device accesscode is entered into the electronic circuit.
 8. The electronic circuitaccording to claim 7, further configured to: authenticate a manufacturerof said device; provide, during device manufacturing, said device accesscode to said device manufacturer in response to successfulauthentication.
 9. The electronic circuit according to claim 1, furtherconfigured to internal access to at least one of said stored secret andsaid device-specific security data unless a predetermined device accesscode is entered into the electronic circuit.
 10. The electronic circuitaccording to claim 1, wherein said electronic circuitry is configuredto: perform additional cryptographic processing based on saidinternally-confined, temporarily available instance of thedevice-specific security data and further external input data togenerate further security data; and perform said security-relatedoperation in response to said further security data.
 11. The electronicaccording to claim 10, wherein said device-specific security datarepresents a private key, and said further external input datarepresents an encryption of said further device-specific security databy the corresponding public key.
 12. The electronic circuit according toclaim 11, wherein said further security data represents a symmetriccontent decryption key issued by a content provider, and saiddevice-specific security data represents a private key of a devicemanufacturer.
 13. The electronic circuit according to claim 1, whereinsaid cryptographic processing engine is configured for generating asymmetric cryptographic key in response to a seed applied over anexternal circuit interface.
 14. The electronic circuit according toclaim 1, wherein said cryptographic processing engine is configured forgenerating an internally-confined, temporarily available private key atleast partly based on said stored secret, and said electronic circuitrycomprises means for performing asymmetric cryptography operations basedon said internally confined, temporarily available private key.
 15. Theelectronic circuit according to claim 14, further configured to: performshared key generation to generate a new shared key based on saidgenerated private key and a public key of an intended communicationpartner; and perform cryptographic processing based on said new sharedkey.
 16. The electronic circuit according to claim 14, furtherconfigured to: generate a public key corresponding to said private keyduring configuration of said device, and output said public key over anexternal circuit interface.
 17. The electronic circuit according toclaim 1, wherein said cryptographic processing engine is configured forgenerating said internally-confined, temporarily available instance ofdevice-specific security data as a chain of k bind keys B₁, . . . ,B_(k) in response to corresponding bind identities R₁, . . . , R_(k)according to the following formula:B _(i) =f(B _(i-1) , R _(i)) for i=1, . . . , k, where B₀ represents thestored secret, and f is a cryptographic one-way function.
 18. A deviceimplemented with a tamper-resistant electronic circuit, said electroniccircuit comprising: a storage unit for tamper-resistantly storing,during manufacture of the tamper-resistant electronic circuit, a randomsecret not accessible over any external circuit interface to thetamper-resistant electronic circuit and unknown after being stored inthe storage device; trigger data generating circuitry for, duringconfiguration of the tamper-resistant electronic circuit, generatingtrigger data by cryptographically combining the random secret anddevice-specific security data that is different from the random secretand outputting the trigger data outside of the tamper-resistantelectronic circuit; a receiver for, during operation of the configuredtamper-resistant electronic circuit by a user, receiving external to thetamper-resistant electronic circuit from the user via an externalcircuit interface the trigger data; a cryptographic processing engine,in response to the externally received trigger data from the user, forperforming cryptographic processing at least partly in response to saidstored secret and the externally received trigger data from the user togenerate a temporarily available instance of the device-specificsecurity data internally confined within said electronic circuit duringusage of said device such that the temporarily available instance of thedevice-specific security data is only available when the externallyreceived trigger data is received; and electronic circuitry, connectedto the cryptographic processing engine and configured to perform asecurity-related operation in response to said internally-confined,temporarily available instance of device-specific security data.
 19. Thedevice according to claim 18, wherein said device is a network deviceand said operation is related to at least one of data confidentiality,data integrity, authentication, authorization and non-repudiation innetwork communication.
 20. The device according to claim 18, whereinsaid device is configured for producing digital content and saidsecurity-related operation is configured for marking said digitalcontent based on said device-specific security data.
 21. The deviceaccording to claim 18, wherein said cryptographic processing engine isconfigured for generating said internally-confined, temporarilyavailable instance of device-specific security data provided thatadditional input data in the form of predetermined trigger data isapplied over an external circuit interface of the electronic circuitduring usage of said device, wherein said trigger data is defined duringconfiguration of said device.
 22. A method for a device, said methodcomprising the steps of: storing, in a controlled environment duringmanufacturing of a tamper-resistant electronic circuit, a secretrandomized number in said electronic circuit such that the secretrandomized number is not available outside of said tamper-resistantelectronic circuit and is unknown after being stored in the storagedevice; during configuration of the tamper-resistant electronic circuit,generating trigger data by cryptographically combining the secretrandomized number and device-specific security data that is differentfrom the secret randomized number and outputting the trigger dataoutside of the tamper-resistant electronic circuit; implementing, duringcircuit manufacturing, functionality into said electronic circuit for,during operation of the configured tamper-resistant electronic circuitby a user, receiving external to the tamper-resistant electronic circuitfrom the user via an external circuit interface the trigger data;implementing, during circuit manufacturing, functionality into saidelectronic circuit for, in response to the externally-received triggerdata from the user, performing cryptographic processing at least partlybased on said stored secret number and the externally-received triggerdata from the user to generate a temporarily available instance of thedevice-specific security data internally confined within said electroniccircuit during usage of the device such that the temporarily availableinstance of the device-specific security data is only available when theexternally received trigger data is received; implementing, duringcircuit manufacturing, a security-related operation into said electroniccircuit, said security-related operation being configured for receivingat least said internally-confined, temporarily available instance ofdevice-specific security data as input during usage of the device; andinstalling, during device manufacturing, said electronic circuit intosaid device.
 23. The method according to claim 22, wherein said deviceis a network device and said operation is related to at least one ofdata confidentiality, data integrity, authentication, authorization andnon-repudiation in network communication.
 24. The method according toclaim 22, wherein said device is configured for producing digitalcontent and said security-related operation is configured for markingsaid digital content based on said internally-confined temporarilyavailable instance of device-specific security data.
 25. The methodaccording to claim 22, further comprising the step of providing, duringconfiguration of the device, trigger data to be applied later duringusage of the device in order to be able to generate saidinternally-confined temporarily available instance of device-specificsecurity data within said electronic circuit.
 26. The method accordingto claim 25, further comprising the steps of: entering, in a controlledenvironment during device configuration, said trigger data as input datainto said electronic circuit in order to obtain device-specific securitydata from the cryptographic functionality of the electronic circuit;recording, in a controlled environment during device configuration, saiddevice-specific security data and said input data; and entering, in acontrolled environment during device configuration, a predetermineddevice access code into the electronic circuit for accessing theinternally-confined temporarily available instance of device-specificsecurity data over an external circuit interface.
 27. The methodaccording to claim 25, further comprising the steps of: generating, in acontrolled environment during device configuration, aninternally-confined temporarily available instance of device-specificsecurity data; entering, in a controlled environment during deviceconfiguration, said generated device-specific security data into saidelectronic circuit in order to obtain said trigger data as a resultrepresentation from the cryptographic functionality of the electroniccircuit; and recording, in a controlled environment during deviceconfiguration, said result representation and the previously generateddevice-specific security data.